Secured communication in network environments

ABSTRACT

A computing device can obtain a session key for encrypting data that is communicated between a client device and the computing device. The computing device can receive, from the client device, an encrypted request for data. The encrypted request can be encrypted by the client device using the session key. The data requested can be stored on a second computing device. The computing device can send, to the second computing device, a copy of the session key and the encrypted request for data. The second computing device can decrypt the data using the session key and can also encrypt data responsive to the request using the session key.

BACKGROUND

Transport Layer Security (TLS) and Secure Sockets Layer (SSL) providecryptographic protocols that allow computing devices to securelycommunicate data over networks, e.g., the Internet. In one example, whenestablishing a secure communication channel, a client and a server canperform a handshake during which the client and the server exchangerandom numbers and a special number called the pre-master secret. Theseexchanged numbers can be combined with other data to generate a sharedsecret, i.e., the master secret, between the client and the server. Theclient and the server can then use the master secret to generate sessionkeys.

The session keys are symmetric cryptographic keys that can be used toencrypt and decrypt data that is communicated between the client and theserver through the secure communication channel. Thus, for example, oncethe session keys have been generated, the client can encrypt data to besent to the server using the generated session key and, upon receivingthe encrypted data, the server can use the generated session key todecrypt the encrypted data. Typically, a secure communication channel isneeded to protect data being exchanged between the client and the serverfrom being seen by third-party observers.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present disclosure will bedescribed with reference to the drawings, in which:

FIG. 1 illustrates an example diagram showing an end-to-end securecommunication channel between computing devices;

FIG. 2 illustrates another example diagram showing an end-to-end securecommunication channel between computing devices;

FIG. 3 is an example protocol stack for implementing an end-to-endsecure communication channel between computing devices;

FIG. 4 illustrates an example sequence diagram showing communicationbetween computing devices over an end-to-end secure communicationchannel;

FIG. 5 illustrates an example diagram showing a distributed computeenvironment allowing parallelization of end-to-end secure communicationchannels between computing devices;

FIG. 6 illustrates an example diagram showing a distributed computeenvironment with a server that implements a combiner;

FIG. 7 is a flow diagram of an example process for implementing anend-to-end secure communication channel between computing devices; and

FIG. 8 illustrates an example logical arrangement of a set of generalcomponents of an example computing device.

DETAILED DESCRIPTION

Systems and methods in accordance with various embodiments of thepresent disclosure overcome one or more of the above-describeddeficiencies and other deficiencies in conventional approaches tosecuring communication channels between computing devices. Inparticular, various embodiments of the present disclosure can provideapproaches for providing end-to-end secure communication channels amongcomputing devices.

End-to-end secure communication channels can be created to allow aclient device to securely communicate data with multiple computingdevices using one encryption key. For example, a client device canestablish a session key with a web server for use in encrypting datathat is communicated between the client device and the web server. Insome instances, the client device may want to obtain data that isavailable at a data store that is accessible through the web server. Insuch instances, when an encrypted request for data that is in the datastore is received, the web server can decrypt the request using thesession key, and then re-encrypt the data request using a separateencryption key that is known to the web server and the data store.

During this process, the request is available on the web server in cleartext and is therefore susceptible to being accessed by an unauthorizedthird-party. To remedy this vulnerability, the same session key that wasestablished between the client device and the web server can be sent tothe data store for using in encrypting data. Thus, when an encrypteddata request for data that is in the data store is received, the webserver can forward the data request directly to the data store and thedata store can decrypt the request using the session key. The data storecan then process the request to obtain data that is responsive to therequest, encrypt the responsive data using the session key, and send theencrypted data back through the web server and to the client device.

As a result, the responsibility of performing a handshake, e.g.,generating a session key using, for example, a Transport Layer Securityor a Secure Sockets Layer cryptographic protocol, and the responsibilityof encrypting and decrypting data can be compartmentalized. Differentaccess rights can be set for the different differentially secure andprecisely access controlled compartments to prevent unauthorized accessto data. This compartmentalization is desirable for security reasonsbecause it helps reduce the risk of systems being compromised and therisk of data being leaked. That is, no single compromise will affectother secure communication channels and an attacker would therefore haveto devise multiple points of entry. Further, by restricting thehandshake and the session key to one compartment, or, in some instances,one computing device, multiple sequential handshakes are no longerneeded to communicate with other computing devices, since the samesession key can be shared among the other computing devices. Thisfeature can help reduce latency that results from having to performmultiple handshakes between computing devices. Additionally, someimplementations allow a single session establishment for a one-to-manysecure communication tunnel for multiple transactions.

Other advantages, variations, and functions are described and suggestedbelow as may be provided in accordance with the various embodiments.

FIG. 1 illustrates an example diagram 100 showing an end-to-end securecommunication channel between computing devices 102, 106, and 108. InFIG. 1, a user interacting with a computing device 102, i.e., a client,through a software application executing on the computing device 102, toaccess, over a network 104, a secure website that is hosted by thecomputing device 106, i.e., a web server.

Typically, before accessing the secure website, the client 102 and theweb server 106 will establish a secure communication channel amongthemselves. A secure communication channel can be established byperforming a handshake 105 using generally known cryptographicprotocols, e.g., Transport Layer Security (TLS) or Secure Sockets Layer(SSL).

For example, an example TLS handshake 105 can involve the client 102sending to the web server 106 data describing a generated random numbervalue and a list of cipher suites that are supported by the computingdevice 102. The web server 106 responds by sending the client 102 agenerated random number value and a security certificate, e.g., an X.509security certificate, that includes the web server's public key. Theclient 102 generates a random pre-master secret, encrypts the pre-mastersecret using the web server's public key, and sends, to the web server106, the encrypted pre-master secret. The web server 106 receives anddecrypts the pre-master secret using the web server's private key.

Next, the client 102 and the web server 106 each use the pre-mastersecret to generate a master secret and a session key 112 (“mastersession key”). The master session key 112 can be used to encrypt anddecrypt data that is communicated between the client 102 and the webserver 106. Data that is communicated over the secure communicationchannel is encrypted and is therefore not able to be accessed by athird-party, as it typically would be had the data been communicated inclear text.

The client 102 and the web server 106 can securely communicate data overthe secure communication channel by sending data that has been encryptedusing the master session key 112. For example, the client 102 can send,over the secure communication channel, an encrypted request to the webserver 106 for data that is stored in a data store 110. The request canbe encrypted using the master session key 112 that was establishedbetween the client 202 and the web server 106. After receiving theencrypted request, the web server 106 can decrypt the request using themaster session key 112 and can then process the request to obtain datafrom the data store 110. When obtaining data from the data store 110,the web server 106 and the data store 110 can establish a differentsession key 113, for example, using the handshake described above, to beused for encrypting and decrypting data that is communicated between theweb server 106 and the data store 110.

As a result, the web server 106 and the data store 110 exchange data 116that is encrypted using the different session key 113 while the webserver 106 and the client 102 exchange data that is encrypted using themaster session key 112. Thus, the web server 106 is tasked withdecrypting the request that is received from the client 102 using themaster session key 112, and then re-encrypting the request using thedifferent session key 113 before sending the request to the data store110. Similarly, the web server 102 is tasked with decrypting data thatis received from the data store 110 using the different session key 113,and then re-encrypting the data using the master session key 112 beforesending the request to the client 102. Generally, this means that datathat is received from the client 102 or from the data store 110 is, atsome point, available on the web server 106 in clear text. Consequently,when available in clear text, this data is susceptible to being accessedby an unauthorized third-party that has access to the web server 106.

In some embodiments, the web server 106 creates an end-to-end securecommunication channel between the client 102 and other computingdevices, e.g., the data store 108, that store data that is beingrequested by the client 102. In such embodiments, the master session key112 that is established between the client 102 and the web server 106,for example, using the handshake described above, is sent by the webserver 106 to the data store 108. The data store 108 can use the mastersession key 112 to encrypt data 114 that is communicated between the webserver 106 and the data store 108. In some embodiments, the web server106 first encrypts the master session key 112, for example, using thedata store's 108 public key, before sending it to the data store 108.Other ways of encrypting the master session key 112 are possible usinggenerally known encrypting techniques. Upon receipt, the data store 108can decrypt the master session key 112 using the data store's 108private key and can then begin encrypting data using the master sessionkey 112.

Further, the web server 106 is no longer tasked with decrypting datathat is received from the data store 110 using a different session key113, and then re-encrypting that data using the master session key 112.Instead, the data store 110 encrypts the data using the master sessionkey 112 and sends the encrypted data 114 to the web server 106. The webserver 106 simply sends the encrypted data 105 to the client 102, andthe client 102 can decrypt the data using the master session key 112.Thus, in such embodiments, data that is received from the client 102 orfrom the data store 110 is no longer decrypted in the web server 106and, as a result, is also not available in clear text in the web server106. In some embodiments, the web server 106 is restricted to sendingcopies of the master session key 112 to other computing devices, e.g.,the data store 108, and cannot use the master session key 112 to decryptdata.

FIG. 2 illustrates another example diagram 200 showing an end-to-endsecure communication channel between computing devices 202, 206, 208,and 210. In FIG. 2, a user interacting with a computing device 202,i.e., a client, through a software application executing on thecomputing device 202, to access, over a network 204, a secure websitethat is hosted by the computing device 208, i.e., a web server. The webserver 208 is located behind the computing device 206, i.e., a reverseproxy.

Typically, before accessing the secure website, the client 202 and thereverse proxy 206 will establish a secure communication channel amongthemselves. A secure communication channel can be established byperforming a handshake 205 using generally known cryptographicprotocols, e.g., Transport Layer Security (TLS) or Secure Sockets Layer(SSL), as described above.

The client 202 and the reverse proxy 206 can securely communicate dataover the secure communication channel by sending data that has beenencrypted using the master session key 212 that was generated as aresult of the handshake 205. The reverse proxy 206 can also serve as anintermediary for facilitating communication between the client 202 andthe web server 208 or the data store 210.

For example, the client 202 can send, through the reverse proxy 206, anencrypted request 220 for data that is stored in a data store 110. Therequest 220 can be encrypted using the master session key 212 that wasestablished between the client 202 and the reverse proxy 206.

After receiving the encrypted request 220, the reverse proxy 206 candecrypt the request using the master session key 212. Typically, thereverse proxy 206 can then communicate with the web server 208 togenerate a second session key, for example, using the cryptographicprotocols described above, to be used for encrypting data that iscommunicated between the reverse proxy 206 and the web server 208. Thereverse proxy 206 can encrypt the request received from the client 202using the second session key and can send the request to the web server208 for processing.

In some embodiments, however, the reverse proxy 206 sends a copy of themaster session key 212 to the web server 208 for using in encryptingdata that is communicated between the reverse proxy 206 and the webserver 208. Optionally, the reverse proxy 206 can encrypt the mastersession key 212, for example, using the web server's 208 public keybefore sending to provide added security for the master session key 212.Other ways of encrypting the master session key 212 are possible usinggenerally known encrypting techniques.

Upon receipt, the web server 208 can decrypt the master session key 212using the web server's 208 private key and can then begin encryptingdata using the master session key 212. In such embodiments, the reverseproxy 206 can send 214 the encrypted request to the web server 208 forprocessing.

The web server 208 can decrypt the request 214 using the master sessionkey 212 and can evaluate the request 214. The web server 208 can obtaindata responsive to the request and can encrypt the obtained data usingthe master session key 212. The web server 208 can send the encrypteddata back to the reverse proxy 206, which then sends the encrypted datato the client 202 for decrypting.

In some instances, to process the request 214, the web server 208 mayneed to communicate with the data store 210 to obtain data. Typically,when accessing the data store 210, the web server 208 can communicatewith the data store 210 to generate a third session key, for example,using the cryptographic protocols described above, to be used forencrypting data that is communicated between the web server 208 and thedata store 210.

To avoid having to generate multiple session keys, in some embodiments,the web server 208 sends a copy of the master session key 212 to thedata store 210 for using in encrypting data that is communicated betweenthe web server 208 and the data store 210. Optionally, the web server208 can encrypt the master session key 212, for example, using the datastore's 210 public key, before sending to provide added security for themaster session key 212. Other ways of encrypting the master session key212 are possible using generally known encrypting techniques.

Upon receipt, the data store 210 can decrypt the master session key 212using the data store's 210 private key and can then process the request.The data store 210 can encrypt data responsive to the request using themaster session key 212 and can send the encrypted data 218 to the webserver 208. The web server 208 can send the data 218 that was encryptedby the data store 210 using the master session key 212 back to thereverse proxy 206. In other words, data that is received from the datastore 210 is no longer decrypted in the web server 208 and, as a result,is also not available in clear text in the web server 208.

Further, the reverse proxy 206 is no longer tasked with decrypting datathat is received from the web server 208, or the data store 210, usingdifferent session keys, and then re-encrypting that data using themaster session key 212 before sending that data to the client 202.Instead, the reverse proxy 206 simply sends, to the client 202, datathat was encrypted by the web server 208, or the data store 210, usingthe master session key 212. The client 202 can decrypt the data usingthe master session key 212. Thus, data that is received from the client202, the web server 208, or from the data store 210 is no longerdecrypted in the reverse proxy 206 and, as a result, is also notavailable in clear text in the reverse proxy 206. In some embodiments,the reverse proxy 206 is restricted to sending copies of the mastersession key 112 to other computing devices, e.g., the data store 210,and cannot use the master session key 112 to decrypt data.

By handing off the master session key 212 to multiple computing devices,as described above, an end-to-end secure communication channel can beestablished between the client 202 and other computing devices, e.g.,the data store 210, that store data that is being requested by theclient 202.

In some embodiments, when the client 202 sends an encrypted request,which was encrypted using the master session key 212, for data that isstored on the data store 210, the reverse proxy 206 sends 222 a copy ofthe master session key 212 along with the encrypted request directly tothe data store 210 while bypassing the web server 208. As a result, theweb server 208 is isolated from the process of sharing the mastersession key 212. In such embodiments, the reverse proxy 206 can encryptthe master session key 212, for example, using the data store's 210public key, before sending to provide added security for the mastersession key 212. Other ways of encrypting the master session key 212 arepossible using generally known encrypting techniques.

In some embodiments, when the client 202 sends an encrypted request,which was encrypted using the master session key 212, for data that isstored on the data store 210, the reverse proxy 206 sends 222 a copy ofthe master session key 212 along with the encrypted request directly tothe data store 210 while bypassing the web server 208. In suchembodiments, the data stream being send by the web server 208 maycontain a mixture of encrypted and unencrypted data. For example, theencrypted data can be the data forwarding from the web server'sinteractions with the data store 210, as described above. The web server208 can send this encrypted data along with its own unencrypted data tothe reverse proxy 206. The reverse proxy 206 can use the master sessionkey 212 to encrypt the data stream being sent by the web server 208 thatcontains the mixture of encrypted and unencrypted data. As a result, theclient device 202 receives, from the reverse proxy 206, an encrypteddata stream that includes the mixture of encrypted and unencrypted data.

In some embodiments, a separate computing device, for example, aHardware Security Module (HSM), can be used to perform the handshake,e.g., the TLS/SSL handshake, with the client 202, and to generate themaster session key 212, as described above. In such embodiments, the HSMcan be configured to send a copy of the master session key 212 directlyto other relevant computing devices, e.g., the data store 210, whilebypassing the reverse proxy 206 and the web server 208 entirely. The HSMcan encrypt the session key, for example, using the data store's publickey, prior to sending. As a result, the reverse proxy 206 and the webserver 208 do not have a copy of the master session key 212 with whichthey can decrypt data that is sent from the data store 210 to the client202 through the web server 208 or the reverse proxy 206. In someembodiments, the HSM is restricted to sending copies of the mastersession key 212 to other computing devices, e.g., the data store 210,and cannot use the master session key 212 to decrypt data.

FIG. 3 is an example protocol stack 300 for implementing an end-to-endsecure communication channel between computing devices. For example, theprotocol stack 300 can be implemented in a computing device, e.g., thecomputing device 208, described above in reference to FIG. 2. Theprotocol stack 300 can be used to allow creation of an end-to-end securecommunication channel between computing devices, for example, bypermitting copies of a session key to be sent to multiple computingdevices. At least some of the components, e.g., the application layer302 and the TLS/SSL layer 306, can be implemented within securecompartments, as described above. Although the protocol stack isdescribed as implementing Transport Layer Security or Secure SocketsLayer, other protocols may be used depending on the implementationincluding, for example, Datagram TLS (DTLS). Further, depending on theprotocol implemented, further changes to the protocol stack may beimplemented as needed.

The protocol stack 300 is configured to encrypt data that is sent over anetwork, e.g., the Internet, between a first computing device and asecond computing device. Data that is generated by services 304, e.g.,HTTPS (HyperText Transfer Protocol Secure), that are operating at theapplication layer 302 can be encrypted, for example, using TransportLayer Security (TLS) or Secure Sockets Layer (SSL) at the TLS/SSL layer306. The TLS/SSL layer 306 can be layered between the application layer302 and the transport layer 318 so that application data can beencrypted before being sent to the transport layer 318. The transportlayer 318 can employ various network communication protocols 320, e.g.,TCP/IP, to send and receive data to and from other computing devices.

The TLS/SSL layer 306 can include a handshake component 308 that isconfigured to perform a handshake, e.g., a TLS/SSL handshake, with othercomputing devices, as described above. The TLS/SSL layer 306 alsoincludes a session key generator 310 that is configured to generatesession keys to be used for encrypting data, as described above. TheTLS/SSL layer 306 also includes a data processing component 312 that canreceive and encrypt data from the application layer 302 and send theencrypted data to the transport layer 318. The data processing component312 can encrypt and decrypt data using, for example, a session key thatwas established between a first and second computing device using thehandshake component 308. In some embodiments, the TLS/SSL layer 306includes a session key sharing component 316 that is configured to sendcopies of session keys to other computing devices, as described above inreference to FIGS. 1, 2, 5, and 6.

In some embodiments, access rights can be specified that define a levelof access to session keys with respect to the handshake component 308,the session key generator 310, the data processing component 312, or thesession key sharing component 316. For example, a computing device canbe configured so that it can access a particular session key using thesession key sharing component 316 but not using the data processingcomponent 312. That is, the computing device can be configured to sharethe particular session key with other computing devices but not todecrypt data using the particular session key.

FIG. 4 illustrates an example sequence diagram 400 showing communicationbetween computing devices over an end-to-end secure communicationchannel. The diagram 400 shows interaction between a client device 402,a first server 404, and a second server 406.

The client device 402 and the first server 404 can perform an encryptionhandshake 410, e.g., TLS/SSL or a different encryption technique, toestablish a secure communication channel through which encrypted datawill be communicated, as described above. When performing the handshake410, the client device 402 and the first server 404 will each generate asession key for encrypting data, as described above.

The client device 402 can send the first server 404 a request 412 fordata that is stored on the second server 406. The request can beencrypted using the session key that was generated during the handshake410. In this example, the second server 406 is not directly accessibleto the client device 402, but can be accessed by the first server 404.Thus, the first server 404 will need to send the request 412 to thesecond server 406 for processing. In some embodiments, the first server404 sends, to the second server 406, a copy of the session key, togetherwith the request 412 that was sent by the client device 414. The copy ofthe session key, together with the request 412 is sent from the firstserver 404 to the second server 406 over a different securecommunication channel that is established between the first server 404and the second server 406. That is, a different encryption handshake 409is performed between the first server 404 and the second server 406before the session key and request are sent from the first server 404 tothe second server 406. In particular, the session key sent to the secondserver 406 is the same session key that was generated by the clientdevice 402 and the first server 404 during the handshake 410. The firstserver 404 can encrypt the session key before sending to the secondserver 406 using, for example, the second server's 406 public key. Insome embodiments, the first server 404 is restricted to sending copiesof the master session key 112 to other computing devices, e.g., thesecond server 406, and cannot use the master session key 112 to decryptdata.

The second server 406 can decrypt the request 412 using the session key.After processing the request 412, the second server 406 can encrypt dataresponsive to the request 412 using the session key, and can send theencrypted data back to the first server 416. The first server 404 cansend the encrypted data to the client device 418. The client device 402can decrypt the data using the session key to view its contents. As aresult, an end-to-end secure communication channel is establishedbetween the client device 402 and the second server 406. In other words,the first server 404 no longer needs to decrypt data that is receivedfrom the second server 406, for example, using a separate encryption keythat was established between the first server 404 and the second server406, and then re-encrypt the data using the session key before sendingthe data to the client device 402.

FIG. 5 illustrates an example diagram 500 showing a distributed computeenvironment allowing parallelization of end-to-end secure communicationchannels between computing devices 502, 510, 530, and 540. In FIG. 5, auser interacting with a computing device 502, i.e., a client, through asoftware application executing on the computing device 502, to access,over a network 523, a secure website that is hosted by the computingdevice 520, i.e., a web server. The web server 520 is located behind thecomputing device 510, i.e., a reverse proxy. The environment includesworkflow servers 530, e.g., the workflow server 531. The user device 502can perform an encryption handshake, e.g., a TLS/SSL handshake, with thereverse proxy 510. Separate individual encryption handshakes, e.g.,TLS/SSL handshakes, can be performed between each workflow server, e.g.,the workflow server 531, and each backend system 541, 542, 543, 544, and545. That is, each separate session that results from a handshake isassociated with a separate encryption key, and each encryption key isassociated with a key identifier that can be used to identify that key'scorresponding session.

The distributed compute environment is organized as a Service OrientedArchitecture (SOA) that includes several backend systems 541, 542, 543,544, and 545 that may be involved in servicing a request submitted bythe user. Each backend systems 541, 542, 543, 544, and 545 can eachperform a different function that is needed to process requests. Forexample, the system 541 can be configured to process a fee associatedwith a user request, the system 542 can store content that can beprovided in response to a user request, the system 543 can managecontent rights, e.g., whether a particular user can or cannot accessparticular content, the system 544 can authenticate the user that issending a request for content, and the system 545 can be configured tovalidate the user request in miscellaneous ways. The SOA architecture isconfigured to allow parallelization in gathering data and transportingdata over secure links, for example, to the computing device 502, usingthe master session key 505 that was established between the computingdevice 502 and the computing device 510.

Data collected from the backend systems 541, 542, 543, 544, and 545 canbe assembled by an intermediary server, e.g., the workflow server 531.In such instances, the intermediary server, e.g., the workflow server531, would have access to the master session key 505 so that the server531 is able to encrypt the data using the master session key 505 andforward the encrypted data, for example, to the reverse proxy 510, tosend to the computing device 502. Depending on the implementation,access to a master session key 505 can key can be restricted to thosesystems that are involved in the assembling of data, e.g., the workflowserver 531. That is, in such implementations, the webserver 520 and thebackend systems 540 can be restricted from having access to the mastersession key 505.

For example, in FIG. 5, the back-end services 541, 542, 543, 544, and545 can communicate each other and return data to the work flow servers530, e.g., the work flow server 531. The work flow server 531 canassemble the data received from the back-end services and form the replyor notification that the work flow has either completed successfully orfailed. The servers in the distributed architecture implement the securecompartmentalization, for example, as described in reference to FIG. 3,such that multiple requests are handled and processed over an indefinitenumber of servers all implementing the secure compartmentalization andbinding transactions to the Session ID, e.g., the one corresponding tothe computing device 502 and encrypting with the master session key 505for that request/session identifier. A similar approach would be appliedfor a different computing device 522 that is accessing the SOA. That is,the SOA architecture is configured to allow parallelization in gatheringdata and transporting data over secure links to the computing device522, using the master session key 525 that was established between thecomputing device 522 and the computing device 510.

In some implementations, the intermediary server, e.g., the workflowserver 531, is configured to send the master session key 505 to at leastone of the backend systems 541, 542, 543, 544, and 545, for use inencrypting data that is sent back to the intermediary server, dependingon which backend server is needed to process the request. In someimplementations, the workflow server 531 includes a combiner that isconfigured to combine data that is received from the multiple backendsystems 541, 542, 543, 544, and 545, as described in reference to FIG.6.

FIG. 6 illustrates an example diagram 600 showing a distributed computeenvironment with a server 604 that implements a combiner 606 that isconfigured to combine data that is received from the multiple backendsystems 610, 612, 614, and 616. For example, in some instances, theserver 604 may be configured to send a master session key 605 that wasgenerated between a handshake between the computing device 602 and theserver 604. The server 604 can send the master session key 605 to some,but not all, of the backend systems. In such instances, the server 604is configured to combine data that is received from the backend systems,some of which may be encrypted using the master session key 605 and somewhich may not, and forward the combined data to be sent to the computingdevice 602. When combining the data, the server 604 can encrypt, usingthe master session key 605, the data received from the backend systems,whether it was encrypted by the master session key 605 or not, so thatthe data stream sent to the computing device 602 is all encrypted usingthe master session key 605.

In some implementations, there may be multiple ongoing sessions betweenuser devices and the server 604 that each have a respective mastersession keys that was established during a handshake with the server604. In such instances, the combiner 606 can be implemented to use keyidentification and key management techniques to determine which mastersession key to use in combining and encrypted a data stream for aparticular user device. In some implementations, a metadata string thatis bound to the master session key and the session itself can be used todistinguish between keys. For example, in TLS/SSL, this string is calledthe SessionID which describes the key and other elements of thetransaction. Thus, in some implementations, the master session keyincludes the actual key used for encryption and decryption, togetherwith a session identifier as metadata for use in identifying the key toall of computing devices involved. In such instances, the computingsystem sending an encrypted data stream can identify the encrypted datausing the session identifier. Similarly, systems on either end of atransaction can use the session identifier to identify the session andunequivocally identify the correct key for that session.

FIG. 7 is a flow diagram of an example process 700 for implementing anend-to-end secure communication channel between computing devices. Theexample process 700 is provided merely as an example and additional orfewer steps may be performed in similar or alternative orders, or inparallel, within the scope of the various embodiments described in thisspecification.

A computing device generates a session key for encrypting data that iscommunicated between a client device and the computing device 702. Thecomputing device receives, from the client device, an encrypted requestfor data 704. The encrypted request can be encrypted by the clientdevice using a separately generated copy of the session key. Further, inthis example, the data being requested can be stored on a secondcomputing device.

The computing device sends, to the second computing device, a copy ofthe session key and the encrypted request for data 706. The secondcomputing device can decrypt the request for data using the session keyand can obtain data that is responsive to the request. The secondcomputing device can then encrypt the obtained data using the sessionkey and can send the encrypted data back to the computing device.

Once received, the computing device can send the data encrypted usingthe session key to the client device. The client device can then decryptthe data using the session key that was independently generated on theclient device and can view the contents of the data. In someembodiments, the computing device is restricted to sending copies of thesession key to other computing devices, e.g., the second computingdevice, and cannot use the session key to decrypt data.

FIG. 8 illustrates a logical arrangement of a set of general componentsof an example computing device 800. In this example, the device includesa processor 802 for executing instructions that can be stored in amemory device or element 804. As would be apparent to one of ordinaryskill in the art, the device can include many types of memory, datastorage, or non-transitory computer-readable storage media, such as afirst data storage for program instructions for execution by theprocessor 802, a separate storage for images or data, a removable memoryfor sharing information with other devices, etc. The device typicallywill include some type of display element 806, such as a touch screen orliquid crystal display (LCD), although devices such as portable mediaplayers might convey information via other means, such as through audiospeakers. As discussed, the device in many embodiments will include atleast one image capture element 808 such as a camera or infrared sensorthat is able to image projected images or other objects in the vicinityof the device. Methods for capturing images or video using a cameraelement with a computing device are well known in the art and will notbe discussed herein in detail. It should be understood that imagecapture can be performed using a single image, multiple images, periodicimaging, continuous image capturing, image streaming, etc. Further, adevice can include the ability to start and/or stop image capture, suchas when receiving a command from a user, application, or other device.The example device similarly includes at least one audio capturecomponent 812, such as a mono or stereo microphone or microphone array,operable to capture audio information from at least one primarydirection. A microphone can be a uni- or omni-directional microphone asknown for such devices.

In some embodiments, the computing device 800 of FIG. 8 can include oneor more communication elements (not shown), such as a Wi-Fi, Bluetooth,RF, wired, or wireless communication system. The device in manyembodiments can communicate with a network, such as the Internet, andmay be able to communicate with other such devices. In some embodimentsthe device can include at least one additional input device able toreceive conventional input from a user. This conventional input caninclude, for example, a push button, touch pad, touch screen, wheel,joystick, keyboard, mouse, keypad, or any other such device or elementwhereby a user can input a command to the device. In some embodiments,however, such a device might not include any buttons at all, and mightbe controlled only through a combination of visual and audio commands,such that a user can control the device without having to be in contactwith the device.

The device 800 also can include at least one orientation or motionsensor 810. As discussed, such a sensor can include an accelerometer orgyroscope operable to detect an orientation and/or change inorientation, or an electronic or digital compass, which can indicate adirection in which the device is determined to be facing. Themechanism(s) also (or alternatively) can include or comprise a globalpositioning system (GPS) or similar positioning element operable todetermine relative coordinates for a position of the computing device,as well as information about relatively large movements of the device.The device can include other elements as well, such as may enablelocation determinations through triangulation or another such approach.These mechanisms can communicate with the processor 802, whereby thedevice can perform any of a number of actions described or suggestedherein.

As an example, a computing device can capture and/or track variousinformation for a user over time. This information can include anyappropriate information, such as location, actions (e.g., sending amessage or creating a document), user behavior (e.g., how often a userperforms a task, the amount of time a user spends on a task, the ways inwhich a user navigates through an interface, etc.), user preferences(e.g., how a user likes to receive information), open applications,submitted requests, received calls, and the like. As discussed above,the information can be stored in such a way that the information islinked or otherwise associated whereby a user can access the informationusing any appropriate dimension or group of dimensions.

The various embodiments can be implemented in a wide variety ofoperating environments, which in some cases can include one or more usercomputers, computing devices, or processing devices which can be used tooperate any of a number of applications. User or client devices caninclude any of a number of general purpose personal computers, such asdesktop or laptop computers running a standard operating system, as wellas cellular, wireless, and handheld devices running mobile software andcapable of supporting a number of networking and messaging protocols.Such a system also can include a number of workstations running any of avariety of commercially-available operating systems and other knownapplications for purposes such as development and database management.These devices also can include other electronic devices, such as dummyterminals, thin-clients, gaming systems, and other devices capable ofcommunicating via a network.

Various aspects also can be implemented as part of at least one serviceor Web service, such as may be part of a service-oriented architecture.Services such as Web services can communicate using any appropriate typeof messaging, such as by using messages in extensible markup language(XML) format and exchanged using an appropriate protocol such as SOAP(derived from the “Simple Object Access Protocol”). Processes providedor executed by such services can be written in any appropriate language,such as the Web Services Description Language (WSDL). Using a languagesuch as WSDL allows for functionality such as the automated generationof client-side code in various SOAP frameworks.

Most embodiments utilize at least one network that would be familiar tothose skilled in the art for supporting communications using any of avariety of commercially-available protocols, such as TCP/IP, OSI, FTP,UPnP, NFS, CIFS, and AppleTalk. The network can be, for example, a localarea network, a wide-area network, a virtual private network, theInternet, an intranet, an extranet, a public switched telephone network,an infrared network, a wireless network, and any combination thereof.

In embodiments utilizing a Web server, the Web server can run any of avariety of server or mid-tier applications, including HTTP servers, FTPservers, CGI servers, data servers, Java servers, and business mapservers. The server(s) also may be capable of executing programs orscripts in response requests from user devices, such as by executing oneor more Web applications that may be implemented as one or more scriptsor programs written in any programming language, such as Java®, C, C# orC++, or any scripting language, such as Perl, Python, or TCL, as well ascombinations thereof. The server(s) may also include database servers,including without limitation those commercially available from Oracle®,Microsoft®, Sybase®, and IBM®.

The environment can include a variety of data stores and other memoryand storage media as discussed above. These can reside in a variety oflocations, such as on a storage medium local to (and/or resident in) oneor more of the computers or remote from any or all of the computersacross the network. In a particular set of embodiments, the informationmay reside in a storage-area network (“SAN”) familiar to those skilledin the art. Similarly, any necessary files for performing the functionsattributed to the computers, servers, or other network devices may bestored locally and/or remotely, as appropriate. Where a system includescomputerized devices, each such device can include hardware elementsthat may be electrically coupled via a bus, the elements including, forexample, at least one central processing unit (CPU), at least one inputdevice (e.g., a mouse, keyboard, controller, touch screen, or keypad),and at least one output device (e.g., a display device, printer, orspeaker). Such a system may also include one or more storage devices,such as disk drives, optical storage devices, and solid-state storagedevices such as random access memory (“RAM”) or read-only memory(“ROM”), as well as removable media devices, memory cards, flash cards,etc.

Such devices also can include a computer-readable storage media reader,a communications device (e.g., a modem, a network card (wireless orwired), an infrared communication device, etc.), and working memory asdescribed above. The computer-readable storage media reader can beconnected with, or configured to receive, a computer-readable storagemedium, representing remote, local, fixed, and/or removable storagedevices as well as storage media for temporarily and/or more permanentlycontaining, storing, transmitting, and retrieving computer-readableinformation. The system and various devices also typically will includea number of software applications, modules, services, or other elementslocated within at least one working memory device, including anoperating system and application programs, such as a client applicationor Web browser. It should be appreciated that alternate embodiments mayhave numerous variations from that described above. For example,customized hardware might also be used and/or particular elements mightbe implemented in hardware, software (including portable software, suchas applets), or both. Further, connection to other computing devicessuch as network input/output devices may be employed.

Storage media and computer readable media for containing code, orportions of code, can include any appropriate media known or used in theart, including storage media and communication media, such as but notlimited to volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage and/or transmissionof information such as computer readable instructions, data structures,program modules, or other data, including RAM, ROM, EEPROM, flash memoryor other memory technology, CD-ROM, digital versatile disk (DVD) orother optical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed bythe a system device. Based on the disclosure and teachings providedherein, a person of ordinary skill in the art will appreciate other waysand/or methods to implement the various embodiments.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the invention asset forth in the claims.

What is claimed is:
 1. A computer-implemented method, the methodcomprising: obtaining, at a first computing device, a session key forencrypting data that is communicated between a client device and thefirst computing device; receiving, from the client device, an encryptedrequest for data, wherein the encrypted request was encrypted by theclient device using the session key, and wherein the data beingrequested is stored on a second computing device that is accessible tothe first computing device; sending, to the second computing device andover an independently secure channel between the first computing deviceand the second computing device, a copy of the session key and theencrypted request for data; receiving, from the second computing deviceand over the independently secure channel between the first computingdevice and the second computing device, encrypted data that isresponsive to the request, the data responsive to the request havingbeen encrypted by the second computing device using the session key; andsending, to the client device, the encrypted data that is responsive tothe request, wherein the client device is configured to decrypt, usingthe session key, the data that is responsive to the request.
 2. Thecomputer-implemented method of claim 1, wherein obtaining the sessionkey at the first computing device, wherein the session key is able toencrypt data that is communicated between the client device and thefirst computing device further comprises: receiving, from the clientdevice and at the first computing device, data for establishing a securecommunication channel between the client device and the first computingdevice; performing, with the client device, a cryptographic protocolhandshake; and generating, in response to performing the handshake, thesession key for encrypting data that is communicated between the clientdevice and the first computing device.
 3. The computer-implementedmethod of claim 1, further comprising: receiving, from the clientdevice, a different encrypted request for data, wherein the differentencrypted request was encrypted by the client device using the sessionkey, and wherein the data being requested is stored on a third computingdevice that is accessible to the first computing device; sending, to thethird computing device, a copy of the session key and the differentencrypted request for data; receiving, from the third computing device,encrypted data that is responsive to the different request, the dataresponsive to the request having been encrypted by the third computingdevice using the session key; and sending, to the client device, theencrypted data that is responsive to the different request, wherein theclient device is configured to decrypt, using the session key, the datathat is responsive to the different request.
 4. The computer-implementedmethod of claim 1, wherein sending, to the second computing device andover the independently secure channel between the first computing deviceand the second computing device, a copy of the session key and theencrypted request for data further comprises: obtaining a public keyassociated with the second computing device; encrypting the session keyusing the public key associated with the second computing device; andsending, to the second computing device, the session key encrypted usingthe public key associated with the second computing device, wherein thesecond computing device is configured to decrypt the session key using aprivate key associated with the second computing device.
 5. Thecomputer-implemented method of claim 1, the method further comprising:restricting the first computing device to sending the session key to thesecond computing device, wherein the first computing device cannotaccess the session key to decrypt data.
 6. A computing devicecomprising: one or more processors; and memory storing instructionsthat, when executed by the one or more processors, cause the computingdevice to perform operations, comprising: obtaining a session key forencrypting data that is communicated between a client device and thecomputing device; receiving, from the client device, an encryptedrequest for data, wherein the encrypted request was encrypted by theclient device using the session key, and wherein the data beingrequested is stored on a second computing device; sending, to the secondcomputing device and over an independently secure channel between thecomputing device and the second computing device, a copy of the sessionkey and the encrypted request for data; receiving, over theindependently secure channel between the computing device and the secondcomputing device, encrypted data that is responsive to the request, thedata responsive to the request having been encrypted by the secondcomputing device using the session key; and sending, to the clientdevice, the encrypted data that is responsive to the request.
 7. Thecomputing device of claim 6, wherein the operations further comprise:establishing an independently secure communication channel between thecomputing device and the second computing device by obtaining adifferent session key for encrypting data that is communicated betweenthe computing device and the second computing device.
 8. The computingdevice of claim 6, wherein the operations further comprise: receiving,from the client device, a different encrypted request for data, thedifferent encrypted request having been encrypted by the client deviceusing the session key, wherein the data being requested is stored on afourth computing device, and wherein the fourth computing device isconfigured to send data through a third computing device; and sending,to the fourth computing device, a copy of the session key and thedifferent encrypted request for data.
 9. The computing device of claim8, wherein the session key and the encrypted request for data are notsent to fourth computing device through the third computing device. 10.The computing device of claim 8, wherein the operations furthercomprise: receiving, from the third computing device, encrypted datathat is responsive to the request, the data responsive to the requesthaving been generated and encrypted by the fourth computing device, theencryption being performed using the session key; and sending, to theclient device, the encrypted data that is responsive to the differentrequest, wherein the third computing device does not have a copy of thesession key to decrypt the encrypted data that is responsive to thedifferent request.
 11. The computing device of claim 6, wherein theoperations further comprise: restricting the computing device to sendingthe session key to the second computing device, wherein the computingdevice cannot access the session key to decrypt data.
 12. The computingdevice of claim 6, wherein obtaining the session key for encrypting datathat is communicated between the client device and the computing devicefurther comprises: receiving, from the client device, data forestablishing a secure communication channel between the client deviceand the computing device; performing, with the client device, acryptographic protocol handshake; and generating, in response toperforming the handshake, the session key for encrypting data that iscommunicated between the client device and the computing device.
 13. Thecomputing device of claim 12, wherein the computing device includes afirst module that is configured to perform the cryptographic protocolhandshake, and to generate the session key, a second module that isconfigured to encrypt and decrypt data using the session key, and athird module that is configured to send the session key to a computingdevice.
 14. The computing device of claim 13, wherein the first module,the second module, and the third module are able to be configured withdifferent access rights to the session key.
 15. The computing device ofclaim 13, wherein the computing device is restricted to performing thecryptographic protocol handshake, and to send the session key to thesecond computing device, and wherein the second computing device is ableto encrypt and decrypt data using the session key.
 16. The computingdevice of claim 6, wherein sending, to the second computing device, acopy of the session key and the encrypted request for data furthercomprises: obtaining a public key associated with the second computingdevice; encrypting the session key using the public key associated withthe second computing device; and sending, to the second computingdevice, the session key encrypted using the public key associated withthe second computing device, wherein the second computing device isconfigured to decrypt the session key using a private key associatedwith the second computing device.
 17. A computing device comprising: oneor more processors; and memory storing instructions that, when executedby the one or more processors, cause the computing device to performoperations, comprising: receiving, from a first computing device andover an independently secure communication channel between the computingdevice and the first computing device, a session key and an encryptedrequest for data, the encrypted request for data having been encryptedusing the session key, and the encrypted request for data having beentransmitted from a client device to the first computing device, whereinthe session key was established between the client device and the firstcomputing device; processing, using the session key, the encryptedrequest for data to obtain data that is responsive to the request;encrypting, using the session key, the obtained data; and sending, overthe independently secure communication channel between the computingdevice and the first computing device, the encrypted data to the firstcomputing device.
 18. The computing device of claim 17, wherein thesession key is encrypted using a public key associated with thecomputing device, and wherein the operations further comprise:decrypting the session key using a private key associated with thecomputing device.
 19. The computing device of claim 17, wherein thesession key was established between the client device and the firstcomputing device in response to a cryptographic protocol handshakebetween a client device and the first computing device.
 20. Thecomputing device of claim 17, wherein the operations further comprise:receiving, from the first computing device, a different encryptedrequest for data, the different encrypted request for data having beenencrypted using the session key, and wherein the data being requested isstored on a second computing device, the second computing device beingaccessible by the computing device; sending, to the second computingdevice and over a different independently secure communication channelbetween the computing device and the second computing device, a copy ofthe session key and the different encrypted request for data; receiving,from the second computing device and over the different independentlysecure communication channel between the computing device and the secondcomputing device, encrypted data that is responsive to the differentrequest, the data responsive to the different request having beenencrypted by the second computing device using the session key; andsending, to the first computing device and over the independently securecommunication channel between the computing device and the firstcomputing device, the encrypted data that is responsive to the differentrequest.